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1  Introduction 

This  document  proposes  a  framework  and  subsystem  for  networking  in  the  Tera  Operating  System. 

1.1  Requirements 

The  primary  focus  is  to  provide  robust  and  timely  TCP/IP  functionality  for  the  Tera.  However, 
the  design  also  accommodates  the  provision  of  NFS,  OSI  and  ATM^  in  the  future. 

1.2  Goals 

From  a  performance  perspective,  the  challenge  is  for  the  networking  subsystem  to  be  ubiquitious 
and  lightweight  enough  to  ‘make  the  hardware  the  bottleneck.’ 

To  achieve  this  goal  on  the  Tera’s  massively  parallel  architecture,  this  design  attempts  to  minimize 
the  following: 

1.  lock  contention, 

2.  data  movement, 

3.  checksum  computation. 

(2)  and  (3)  are  the  traditional  bottlenecks  in  uniprocessor  TCP/IP  implementations.  However, 
the  actual  bottlenecks  of  network  performance  on  the  Tera  system  can  only  be  identified  after 
benchmarks  are  run  on  the  actual  system,  and  execution  profiles  examined. 


^Asynchronous  Transfer  Mode 
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2  Choice  of  Code  Base 


Basically,  this  document  proposes  that  the  networking  components  of  Unix  4.4  BSD  be  adapted 
for  the  Tera  Operating  System.  Apart  from  Unix  4.4  BSD,  the  x-kernel  and  Parallel  STREAMS 
were  also  considered. 

2.1  Unix  4.4  BSD 

A  TCP/IP  implementation  based  on  Unix  4.x  BSD  will  be  widely  interoperable.  Many  TCP/IP 
implementations  are  derived  from  Unix  4.x  BSD.  Consequently,  its  bugs  and  quirks  of  implemen¬ 
tation  have  been  preserved  and  widely  propagated.  It  also  incorporates  significant  public-domain 
contributions,  such  as  Van  Jacobson’s  optimization  work. 

The  Unix  4.x  BSD  sockets  library  is  a  popular  application  programming  interface  for  writing 
network  programs.  By  using  Unix  4.4  BSD  as  a  code  base,  it  will  be  easy  to  provide  a  sockets 
library  for  the  Tera  Operating  System. 

The  Unix  4.4  BSD  release  also  includes  an  NFS  implementation  and  an  OSI  protocol  stack.  Using 
its  TCP/IP  stack  will  facilitate  the  integration  of  its  NFS  and  OSI  implementation  into  the  Tera 
Operating  System. 

The  primary  disadvantage  is  that  the  Unix  4.4  BSD  networking  internals  assume  a  non-preemptive, 
uniprocessor  kernel.  Hence,  major  modifications  to  the  kernel  portions  of  Unix  4.4  BSD  for  the 
Tera  operating  system  will  be  necessary. 

2.2  x-kernel  Version  3.2 

The  x-kernel  is  an  attractive  platform  for  implementing  network  transport  protocol  engines.  It 
is  anticipated  that  research  and  experiments  on  transport  protocols  for  high-performance  gigabit 
networks  will  be  implemented  using  the  x-kernel.  Hence,  the  Tera  Operating  System  will  eventually 
incorporate  the  x-kernel. 

However,  the  current  release  of  the  x-kernel  is  not  suitable  as  the  initial  code  base  for  the  Tera’s 
networking  subsystem,  as  significant  effort  wiU  have  to  be  spent  to: 

1.  provide  a  sockets  library  and  an  interface  for  NFS.  The  current  source  release  is  either  for  a 
Mach  server  or  a  SunOS  user-level  process. 

2.  modify  the  x-kernel  and  the  TCP/IP  modules  for  the  multi-threaded  Tera  Operating  System. 
The  current  release  assumes  that  the  underlying  environment  is  non-preemptive^. 

Also,  it  is  suspected  that  the  TCP/IP  implementation  provided  with  the  current  x-kernel  rekcise 
is  not  as  feature-complete  as  that  of  Unix  4.4  BSD. 

2.3  Parallel  STREAMS 

Parallel  STREAMS  is  the  framework  for  networking  protocols  in  the  Unix  SVR4  ES/MP  kernel 
The  primary  reason  that  it  cannot  be  evaluated  seriously  is  that  its  source  code  is  not  available. 

^Modifications  to  rehost  the  .x-kernel  on  a  multiprocessor  were  discussed  on  the  mailing  list,  xkernel@cs.arizona.edu. 
The  discussions  ranged  from  generalized  queueing  primitives  to  lock-free  approaches  to  protocol  implementation. 
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Part  I 

Functional  Specification 

3  Physical  Interfaces 

All  network  equipment  connect  to  the  Tera  machine  via  HIPPI  channels.  To  connect  the  Tera  to  a 
FDDI  ring,  the  customer  must  acquire  an  IP  router  with  at  least  a  HIPPI  and  a  FDDI  interface. 
Similarly,  to  connect  the  Tera  to  an  Ethernet  segment,  a  T3  line,  or  a  SONET/ATM  network,  the 
customer  must  acquire  HIPPI/Ethernet,  HIPPI/DS3  or  HIPPI/ATM  IP  routers. 

Figure  1  illustrates  the  anticipated  network  topology  of  a  Tera  installation. 

3.1  IP  and  ARP  over  HIPPI 

The  Tera  wiU  transmit  IP  datagrams  over  a  HIPPI  channel  as  specified  by  RFC  1374.  This 
ensures  interconnectivity  with  other  TCP/IP  hosts  and  routers  either  via  a  point-to-point  HIPPI 
connection  or  a  network  of  HIPPI-SC  switches.  The  PCHPI  DX-HIPPI  router  from  Network 
Systems  Corporation  complies  with  RFC  1374,  as  do  routers  from  Computer  Network  Technologies. 

To  resolve  an  IP  address  to  a  HIPPI  I-address  over  a  HIPPI-SC  network,  RFC  1374  specifies  three 
options: 

1.  manual  configuration, 

2.  implementing  ARP  via  an  ARP  server, 

3.  implementing  ARP  using  multicast  functionality. 

Network  Systems  Corporation  implements  only  option  (1).  Similarly,  the  Tera  will  provide  only 
this  option.  Either  the  arp  or  ifconfig  user-level  commands  will  be  used  to  manually  associate  a 
HIPPI  I-address  with  an  IP  address. 

This  does  not  preclude  implementing  options  (2)  or  (3)  in  the  future,  should  customers  demand  it. 
No  router  vendor  contacted  so  far  has  admitted  to  implementing  options  (2)  or  (3). 

3.2  HIPPI  Channel  Allocation 

RFC  1374  encourages  short-lived  HIPPI  connections; 

1.  a  source  should  limit  its  use  of  a  HIPPI  connection  to  64  bursts^.  This  is  at  most  64  or  128  KB 
cumulatively. 

2.  one  HIPPI  packet'*  per  HIPPI  connection  is  acceptable, 


®On  a  point-to-point  HIPPI  link  between  the  Tera  and  an  IP  router,  this  may  cause  HIPPI  connect/disconnect  times 
to  become  significant.  This  will  be  reexamined  after  the  initial  implementation. 

^Each  HIPPI  packet  contains  at  most  one  IP  datagram  or  datagram  fragment. 
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Figure  1:  Physical  Topology  of  a  Tera  Installation 
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However,  a  HIPPI  channel  utilized  for  disk  i/o  will  probably  transmit  larger  packets,  since  the 
HIPPI-FP  specification  allows  HIPPI  packets  to  be  as  big  as  AGb.  This  implies  long-lived  HIPPI 
connections. 

Hence,  since  disk  i/o  and  network  i/o  differ  as  described,  for  performance  reasons,  a  HIPPI  channel 
should  not  be  shared  between  the  two.  At  least  one  HIPPI  channel  wiU  be  dedicated  for  network 
traffic. 

Given  the  potential  bandwidth  of  a  HIPPI  channel  (800M&its  relative  to  that  of  FDDI 
{lOOMbits  s~^),  it  is  anticipated  that  for  most  systems,  a  single  HIPPI  channel  for  network  i/o  will 
suffice.  However,  this  design  does  not  preclude  dedicating  multiple  HIPPI  channels  for  network  i/o. 

A  minimal  production  Tera  system  will  utilize  the  following  HIPPI  channels: 

1.  a  point-to-point  HIPPI  link  to  the  Sun  console  substation  for  the  Tera  console, 

2.  one  or  more  HIPPI  channels  to  RAID  equipment, 

3.  a  dedicated  HIPPI  channel  for  network  i/o. 

A  Tera  system  ha.s  enough  HIPPI  channels  to  satisfy  these  allocations:  even  a  4  processor  system 
will  possess  4  HIPPI  channels.  .  new 

3.3  IP  Interfaces 

From  a  software  perspective,  the  Tera  has  the  following  IP  interfaces: 

1.  loO,  the  software  loopback  device  (IP  address  127.0.0.1), 

2.  hiO,  the  HIPPI  channel  dedicated  to  network  i/o. 
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4  User-Level  Commands  and  Utilities 

In  this  section,  user-level  TCP/IP  utilities  are  partitioned  into  categories  following  the  criteria 
established  for  Tera  operating  system  utilities. 


4.1  Class  2  (Early  Prototype) 


ftp 

ping 

rshd 

ftpd 

rep 

telnet 

hostname 

rlogin 

telnetd 

ifconfig 

rlogind 

tftp 

inetd 

route 

tftpd 

netstat 

rsh 

ttep 

The  applications  enumerated  above  must  be  available  early  in  the  life  of  the  Tera  hardware  proto¬ 
type.  They  enable  remote  access  to  the  Tera  system  for  system  and  compiler  development. 

4.2  Class  3  (First  Customer  Shipment) 


arp 

routed 

talkd 

mkfifo 

ruptime 

tepdump 

named 

rwho 

timed 

named-xfer 

rwhod 

timedc 

nslookup 

syslogd 

traceroute 

rexecd 

talk 

trpt 

rdist 

The  TCP/IP  utilities  enumerated  above  are  expected  of  a  regular  Unix  TCP/IP  release,  and  will 
be  included  in  the  Tera’s  First  Customer  Shipment. 

4.3  Class  4  (After  First  Customer  Shipment) 

gated  htable  whois 

gettable 

While  routinely  included  in  Unix  releases,  the  TCP/IP  utilities  above  can  be  provided  after  the 
First  Customer  Shipment. 

4.4  Class  5  (Never) 

XNSrouted  implogd  tn3270 

implog^  slattach 
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The  Class  5  TCP/IP  utilities  are  either  obsolete  or  inappropriate  for  Tera  systems.  They  will  not 
be  included  in  the  Tera  Operating  System. 


4.5  Deliberate  Omissions 

4.5.1  Yellow  Pages  and  SUN  RPC 

domainname 

rpc.rusersd 

rusers 

portmap 

rpc.rwalld 

spray 

rpc.etherd 

rpc.showflid 

traffic 

rpcJockd 

rpc.sprayd 

ypcat 

rpc.mountd 

rpc.statd 

ypmatch 

rpc.pwdauthd 

rpc.yppasswdd 

yppasswd 

rpc.rexd 

rpc.ypupdated 

ypwhich 

rpc.rquotad 

rpcinfo 

rpc.rstatd 

rup 

This  document  includes  a  plan  to  provide  DNS  functionality,  but  not  Sun’s  Network  Information 
Service,  NIS,  or  NIS+.  The  primary  obstacle  is  the  lack  of  source  code:  Unix  4.4  BSD  does  not 
include  them. 

It  is  not  clear  whether  Tera’s  customers  will  require  NIS.  Here  at  Tera,  the  lack  of  NIS  on  the  Tera 
machine  will  make  system  administration  inconvenient,  but  wiU  not  hinder  its  network  availability. 


4.5.2  Network  File  System 

Although  this  design  will  allow  the  Unix  4.4  BSD  implementation  of  NFS  to  be  easily  integrated, 
NFS  is  out  of  the  scope  of  this  document. 

4.5.3  DCE  and  DME 

This  document  does  not  include  a  plan  for  either  the  OSF  Distributed  Computing  Environment 
or  the  OSF  Distrbuted  Management  Environment.  DCE  includes  Andrew,  Kerberos  and  Apollo 
RPC. 


4.5.4  Network  Queueing  System 

This  document  does  not  include  a  plan  to  provide  a  network  queueing  system. 

4.5.5  Mail 

This  document  does  not  include  a  plan  to  provide  an  electronic  mail  package. 


^The  tnamed  server,  which  supports  the  obsolete  Name  Server  Protocol  specified  by  lEN  116,  will  also  not  be 
supported. 


4.5.6  Simple  Network  Management  Protocol 

The  Unix  4.4  BSD  TCP/IP  implementation  does  not  include  SNMP  functionality.  It  will  have  to 
be  retrofitted  in  the  future.  This  plan  does  not  include  that  work. 

4.5.7  Serial  Line  IP 

Since  the  Tera  machine  wiU  not  have  serial  lines,  a  SLIP  package  will  not  be  provided. 

4.5.8  Reverse  ARP 

Reverse  ARP  is  used  mainly  to  boot  diskless  workstations.  It  relies  on  Ethernet  broadcasts.  The 
Tera  will  not  need  client-side  RARP  functionality.  Also,  since  the  Tera  will  not  be  connected 
directly  to  an  Ethernet  segment,  there  is  no  need  for  a  RARP  server  on  the  Tera,  and  it  will  not 
be  provided. 
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5  Programming  Interfaces 


5.1  User-Level  Interfaces 

The  sockets  interface  is  required  by  Tera’s  potential  customers. 


Sockets  System  Calls 


accept  0 

readO 

sendmsgO 

bindO 

readv ( ) 

setsockoptO 

closeO 

recvO® 

shut down 0 

connect  () 

recvfromO 

socket  0 

getpeernameO 

recvmsgO 

socketpairO 

getsocknameO 

select () 

write 0 

getsockoptO 

sendO® 

writevO 

listenO 

sendtoO 

gethostidO 

Other  Unix  System  Calls 
getkerninfo(KINFO_RT) 

sethostnameO 

gethostnameO 

sethostidO 

FD-CLRO 

Macros 

FD^SETO 

FD^EROO 

FDJSSETO 

dn..comp() 

libc(3N) 

getservbynameO 

ntohsO 

dn_expand() 

getservbyport () 

rcmdO 

endhostentO 

getservent () 

res^init 0 

endnetent 0 

htonlO 

resjnkqueryO 

endprotoent 0 

htonsO 

res-.send() 

gethostbyaddrO 

inet^addrO 

rresvport () 

gethostbyname ( ) 

inet.atonO 

ruserokO 

getnetbyaddrO 

inet_lnaof  () 

sethostentC) 

getnetbynameO 

inet-iricLkeaddr  (  ) 

setnetent 0 

getnetent 0 

inet  Jietof 0 

setprotoent 0 

getprot obyname ( ) 

inet  jietworkO 

setserventO 

getprotobynumberO 

inet_ntoa() 

getprotoent 0 

ntohlO 

^Although  documented  as  system  calls,  sendO  and  recvO  are  actually  library  functions  implemented  with  sendtoO 
and  recvlromO  in  Unix  4.4  BSD. 
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libresolvM 

gethostbyaddrO  resjokqueryO  res_search() 

get  ho  St  byname  (  )  r  es«query  (  )  res^send  (  ) 

libcompatM 

rexecO^ 

5.1.1  Mult i- T  hreaded  Considerat  ions 

gethostbyaddrO  getnetentO 

gethostbyname ( )  getprot obyname ( ) 

gethostentO  getprotobynumberO 

getnetby addr ( )  getprotoent ( ) 

getnetbyname ( )  get s  ervbyname ( ) 

The  libc(3N)  functions  enumerated  above  are  neither  reentrant  nor  thread-safe:  as  defined  by  Unix 
4.4  BSD,  they  return  pointers  to  static  data.  Thread-safe  variants  of  the  functions  will  be  be  defined 
and  implemented. 

5.2  Supervisor-Level  Interfaces 

The  networking  components  that  reside  in  the  Unix  4.4  BSD  kernel  are  organized  into  three  logical 
layers: 

•  the  socket  layer, 

•  the  protocol  layer, 

•  the  network  interface  layer. 

So  that  Unix  kernel-level  components  such  as  NFS  and  other  protocol  stacks  can  be  ported  over  to 
the  Tera,  the  following  networking  interfaces  will  be  available: 

Socket  Layer  Support  Routines 

soacceptO  socreateO  sosendO 

sobindO  sogetoptO  sosetoptO 

socormectO  solistenO  soshutdownO 

soconnect2()  soreceiveO 

^In  Unix  4.4  BSD,  this  has  been  made  obsolete  by  krcmdO). 


getservb3rport() 
getservent 0 
inet_makeaddr() 
inetjitoaO 
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MCHTYPEO 

MEXGETO* 

MFREEO 

MGETO 

MGETHDRO 

MH_ALIGN() 

M_ALIGN() 

M_COPY_PKTHDR() 

MJ-EADINGSPACEO 


mbuf  Management  Routines 

MJ>REPEND() 

M_TRAILINGSPACE() 

dtomO 

m_adj () 

m_cat() 

m_copydata() 

nucopyrnO 

mjfreeO 

m_freem() 


m_get() 

m_getclr() 

m_gethdr() 

m_prepend() 

m_pullup() 

m_split() 

mtodO 


Network  Interface  Layer  Routines 

IF_ENqUEUE()  IF_DEQUEUEIF()  IF-PREPEND() 

IF_DEQUEUE() 


^MEXGETO  replaces  MCLGETO. 
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6  Future  Enhancements 

The  following  features  are  missing  from  the  Unix  4.4  BSD  pre-alpha  release,  and  will  be  added. 


6.1  TCP/EP  Extensions 

6.1.1  High  Performance  TCP 

In  the  Unix  4.4  BSD  pre-alpha  TCP  implementation,  the  maximum  TCP  segment  size  is  64  KB. 
RFC  1323  specifies  a  TCP  window  scale  option  that  allows  TCP  segments  to  be  2  GB.  This  may 
be  necessary  to  achieve  good  TCP  throughput  over  a  HIPPI  channel. 

RFC  1323  also  specifies  a  method  to  timestamp  each  individual  TCP  segment,  so  that  the  round- 
trip-time  of  a  TCP  connection  can  be  accurately  measured. 

6.1.2  MTU  Discovery 


Maximum  Transfer  Unit 


Media 
HIPPI 
ATM  AAL5 
FDDI 
Ethernet 


64  KB 
9180  bytes 
4352  bytes* 
1514  bytes 


Since  the  Maximum  Transfer  Unit,  or  MTU,  for  a  HIPPI  channel  is  much  larger  than  the  MTU  size 
of  FDDI  and  ethernet,  MTU  discovery  as  specified  by  RFCs  1435  and  1191  should  be  implemented 
so  that  it  is  possible  to  send  optimal  sized  TCP  segments  across  IP  routers. 

6.1.3  IP  Multicasting 

IP  multicasting,  as  specified  by  RFC  1112,  may  be  necessary  to  support  multimedia  applications. 

6.2  Buffer  Management 
6.2.1  Extended  Mbufs 

Right  now,  M_EXGET  fails  if  there  isn’t  sufficient  memory  for  an  mbuf  extension  of  the  requested 
size.  This  needs  to  be  refined  so  that  the  caller  calls  M-EXGET  to  get  2  buffers  of  half  the  size,  ... 
and  so  on. 


®page  5,  RFC  1390,  January  1993. 
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Part  II 


Design  and  Implementation 

7  Processing  Activity 

Activity®  within  the  network  subsystem  begins  when: 

1.  data  is  sent  down  a  socket, 

2.  a  packet  is  received  from  the  HIPPI  channel, 

3.  a  function  within  the  network  subsystem  is  fired  because  its  timeout  ()  period  expired. 

7.1  Levels  and  Protection  Domains 

All  network  processing  executes  at  supervisor  level  (LEV^UPER),  either  in: 

1.  the  protection  domain  of  the  task  that  originated  the  activity, 

2.  the  kernel/supervisor  daemon’s  protection  domain. 

(1)  is  desirable  because  it  preserves  the  ‘parallelism  width’  of  a  task,  and  avoids  the  overhead  of 
inter-address  space  communication.  However,  the  process  scheduler  wiU  not  pm-swap  a  task  while 
it  has  chores  executing  at  supervisor  level. 

Hence,  to  prevent  adverse  interaction  with  the  process  scheduler,  an  SP-chore  will  execute  in  the 
network  subsystem  only  for  its  own  benefit.  It  will  avoid  processing  network  packets  that  are  not 
destined  for  it. 

7.2  Parallelism  and  Load  Balancing 

For  efficiency,  throughput  and  scalability,  the  networking  subsystem  will  process  as  many  network 
packets  in  parallel  as  possible.  For  outbound  network  packets,  most  of  this  parallelism  will  be 
achieved  by  relegating  network  processing  to  the  originating  chore,  as  described  in  section  7.1. 

Parallelizing  the  processing  of  inbound  network  packets  is  more  problematic.  As  shown  in  figure  2, 
the  Unix  4.4  BSD  TCP/IP  implementation  processes  network  packets  in  layers.  The  ultimate 
task/chore  destined  to  receive  the  packet,  if  any,  cannot  be  determined  until  the  TCP  header  of  an 
inbound  packet  is  analyzed,  and  associated  with  a  TCP  control  block. 

Hence,  to  process  inbound  network  packets  in  parallel,  it  is  necessary  to  have  concurrent  activ¬ 
ity  within  the  kernel/supervisor  daemon’s  protection  domain.  However  the  ‘parallelism  width’ 
dedicated  to  networking  there  must  satisfy  the  following  constraints: 


®The  acceptO,  bindO,  listenO,  ...system  calls  are  ignored  here. 
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Figure  2:  TCP/IP  Processing 


1.  there  should  not  be  so  many  hardware  streams  processing  network  packets  that  the  parallelism 
of  user-level  tasks  is  affected.  This  occurs  if  the  user-level  scheduler  is  deprived  of  hardware 
streams. 

2.  there  should  not  be  so  few  hardware  streams  processing  network  packets  that  user-level  chores 
blocked  in  a  readO  waiting  for  data  to  percolate  from  the  hardware  interface  up  to  the  socket 
incur  unnecessary  delays. 

However,  when  the  bandwidth  of  a  HIPPI  channel  is  considered  relative  to  the  processing  speed  of 
a  hardware  stream,  it  may  prove  in  practice  that  only  a  few  daemon  chores  are  necessary  to  service 
many  user-level  chores  waiting  within  read(). 


7.3  Using  a  ^Network  Processing  Server’ 


new 


To  facilitate  a  dynamic  ‘parallelism  width’  for  processing  inbound  network  packets,  it  is  tempting 
to  relegate  such  processing  to  a  server  task.  This  task  would  consist  only  of  SPchores,  all  executing 
or  sleepOing  within  the  network  subsystem.  When  parallelism  needs  to  be  widened,  more  chores 
are  created  within  this  task;  when  parallelism  needs  to  be  shrunk,  some  chores  are  destroyed. 

The  problem  with  this  scheme  is  that  the  server  task  will  consume  one  protection  domain  on  each 
physical  processor.  Protection  domains  are  treasured  resources,  there  being  only  16  per  physical 
processor. 

However,  one  protection  domain  on  each  physical  processor  is  already  reserved  for  the  kernel/ supervisor 
daemon.  Hence,  this  design  proposes  that  inbound  network  packets  and  other  such  network  pro¬ 
cessing  take  place  in  the  kernel/supervisor  protection  domain. 


7.4  timeout()  Parallelism 

The  Unix  4.4  BSD  kernel  networking  subsystem  uses  timeout  ()  to  implement  the  following  timers^®: 

1.  a  fast  protocol  timer,  which  fires  5  times  a  second  (once  every  200  ms), 

2.  a  slow  protocol  timer,  which  fires  twice  a  second  (once  every  500  ms), 

3.  the  arp  cache  timer,  which  fires  every  5  minutes. 

ip_slowtimo()  discards  old  IP  fragments  waiting  for  reassembly.  It  is  not  anticipated  that  paral¬ 
lelizing  ip^slowtimoO  or  the  arp  cache  timer  will  contribute  to  any  speedup. 

top  JasttimoO  sends  down  delayed  ACKs  for  those  TCP  connections  that  have  acknowledgments 
pending;  tcp_slowtimo()  retransmits  TCP  segments,  probes  windows,  and  sends  keepalive  heart¬ 
beats  on  those  TCP  connections  that  need  it.  These  two  TCP  timers  will  be  modified  to  process 


^°The  networking  subsystem  also  includes  the  interface  watchdog  timer,  which  fires  once  a  second.  However,  the 
HIPPI  driver  will  probably  not  use  this  timer. 
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individual  TCP  control  blocks  concurrently. 


*  slow  protocol  timer  scheduler 

7 

pfslowtimo() 

{ 

create  a  chore  to  caU  ip_slowtimo(); 
create  a  chore  to  call  tcp_slowtimo(); 
timeout (pfslowtimo,  (caddr_t)  0,  hz/5); 

} 

10 

tcp_slowtimo() 

{  ’ 

register  struct  tcpcb  *tp; 

lock  the  linked  list  of  TCP  control  blocks;  is 

for  (tp  =  head_of_list;  tp;  tp  =  tp->next_in_list)  { 
lock  the  TCP  control  block; 

if  (this  TCP  connection  needs  timeout  processing)  {  20 

increment  reference  count  of  the  TCP  control  block; 
unlock  the  TCP  control  block; 

create  a  chore  to  send  a  packet  down  the  TCP  connection; 

} 

else  {  25 

unlock  the  TCP  control  block; 

} 

} 

unlock  the  linked  list  of  TCP  control  blocks;  30 

} 
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